Methods, Systems, and Products for Secure Acces to File System Structures

ABSTRACT

Methods, systems, and products secure access to a file system. A directory is established in a hierarchical file structure having access permission defined by a first owner. A subdirectory is established in the directory. A sub-level subdirectory is established in the subdirectory having access permissions defined by a second owner. The subdirectory is publically accessible to anyone satisfying the access permission defined by the first owner, such that a change directory system call is executed for a user in the subdirectory, even though the user has not authenticated the access permission defined by the second owner.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.12/326,232 filed Dec. 2, 2008, since issued as U.S. Pat. No. ______, andincorporated herein by reference in its entirety.

BACKGROUND

Exemplary embodiments generally relate to electrical computers anddigital processing systems and, more particularly, to file protectionand security levels.

Computer and network security is a common concern. Nearly every day somevirus, threat, or “hacker” makes the news. Many computer experts thusdevote themselves to developing schemes that improve the security ofsensitive data and files. These past and current schemes, though, areall based on monitoring or alerting when suspicious access patterns aredetected. These conventional schemes are thus best-effort and can onlylimit the amount of data stolen. These conventional schemes cannotprevent data from being stolen. Other conventional schemes also protectusing a single user identification per document repository.

FIG. 1 illustrates one of the conventional security schemes. FIG. 1structurally illustrates POSIX statements for traversing a directorystructure “ . . . d1/d2 . . . ” The POSIX file system semantics make itnearly impossible to traverse the “ . . . d1/d2 . . . ” path as anon-privileged user (that is, a user not possessing the correct rootid), where directories “d1” and “d2” each have “0700” permissions withrespective ownership of u1 and u2. As FIG. 1 illustrates, thenon-privileged user is prevented from traversing the “ . . . d1/d2 . . .” path due to the requirements for executing a “change directory” systemcall. The change directory” system call requires a process to have“search” (e.g., execute) permission in the current directory before theprocess may advance to the next directory. Here, though, directories“d1” and “d2” are accessible only to their respective owners (e.g., user“u1” and user “u2”).

SUMMARY

Exemplary embodiments provide methods, systems, and products forsecuring access to a file system. Exemplary embodiments describe ahierarchical file structure having an access scheme that providesscalable protection for shared, electronic documents. Exemplaryembodiments establish a publically-accessible subdirectory in thehierarchical file structure. That is, if a user successfullyauthenticates the access permissions of an upper-level directory, thenthe user has global search permissions in a lower-level subdirectory.Here, though, the user is held in the subdirectory until the usersuccessfully authenticates any access permissions for lower-levelsubdirectories. The user, then, must satisfy directory-level accesspermissions to access the publically-accessible subdirectory. The user,though, is prevented from accessing lower-level subdirectories untilfurther access permissions are satisfied. Here, then, the user isrequired to authenticate two separate times in order to traverse thehierarchical file structure from the directory, to the subdirectory, andthen to the lower-level subdirectory. This access scheme is scalable,such that N different layers in the hierarchical file structure mayrequire N different authentications.

Exemplary embodiments include a method for securing access to a filesystem. A directory is traversed in a hierarchical file structure havinga first access permission requirement. A subdirectory in the directoryis established that has a global search permission. A sub-levelsubdirectory in the subdirectory is also established having a secondaccess permission requirement. When a user successfully authenticates tothe first access permission requirement of the directory, then the useris permitted to execute a change directory system call in thesubdirectory, even though the user has not authenticated the secondaccess permission requirement for the sub-level subdirectory.

More exemplary embodiments include a system for securing access to afile system. Means are disclosed for establishing a directory in ahierarchical file structure having access permission defined by a firstowner. Means for establishing a subdirectory in the directory isincluded. Means are also included for establishing a sub-levelsubdirectory in the subdirectory having access permissions defined by asecond owner. When a user successfully authenticates the accesspermission of the directory, then means are included for executing achange directory system call in the subdirectory, even though the userhas not successfully authenticated the access permissions defined by thesecond owner.

Still more exemplary embodiments include a computer readable medium thatstores instructions for performing a method of securing access to a filesystem. A processor executes an operating system stored in memory, andthe operating system has a hierarchical file structure. A directory inthe hierarchical file structure is accessed having access permissiondefined by a first owner. A subdirectory in the directory is accessed. Asub-level subdirectory in the subdirectory is read having accesspermission defined by a second owner. A change directory system call isexecuted in the subdirectory for a user that successfully authenticatesthe access permission of the directory, even though the user has notsuccessfully authenticated the access permissions defined by the secondowner for the sub-level subdirectory. An access time for an invaliddirectory path is compared to a threshold access time. When the accesstime equals or exceeds the threshold access time, then the methodnotifies of a security threat.

Other systems, methods, and/or computer program products according tothe exemplary embodiments will be or become apparent to one withordinary skill in the art upon review of the following drawings anddetailed description. It is intended that all such additional systems,methods, and/or computer program products be included within thisdescription, be within the scope of the claims, and be protected by theaccompanying claims.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

These and other features, aspects, and advantages of the exemplaryembodiments are better understood when the following DetailedDescription is read with reference to the accompanying drawings,wherein:

FIG. 1 illustrates a conventional, prior art directory structure;

FIGS. 2 and 3 are simplified schematics illustrating an environment inwhich exemplary embodiments may be implemented;

FIGS. 4 and 5 are screen prints of physical views of an enhanced accesssystem, according to exemplary embodiments;

FIGS. 6-8 are schematics illustrating security enhancements, accordingto exemplary embodiments;

FIGS. 9-13 are schematics illustrating examples of enhanced file accessstructures, according to exemplary embodiments;

FIGS. 14 and 15 are schematics illustrating more examples of enhancedfile access structures, according to exemplary embodiments;

FIG. 16 is a schematic illustrating a generic block diagramincorporating an enhanced directory structure, according to exemplaryembodiments;

FIG. 17 depicts other possible operating environments for additionalaspects of the exemplary embodiments; and

FIGS. 18 and 19 are flowcharts illustrating a method of securing accessto a file system, according to exemplary embodiments.

DETAILED DESCRIPTION

The exemplary embodiments will now be described more fully hereinafterwith reference to the accompanying drawings. The exemplary embodimentsmay, however, be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein. Theseembodiments are provided so that this disclosure will be thorough andcomplete and will fully convey the exemplary embodiments to those ofordinary skill in the art. Moreover, all statements herein recitingembodiments, as well as specific examples thereof, are intended toencompass both structural and functional equivalents thereof.Additionally, it is intended that such equivalents include bothcurrently known equivalents as well as equivalents developed in thefuture (i.e., any elements developed that perform the same function,regardless of structure).

Thus, for example, it will be appreciated by those of ordinary skill inthe art that the diagrams, schematics, illustrations, and the likerepresent conceptual views or processes illustrating the exemplaryembodiments. The functions of the various elements shown in the figuresmay be provided through the use of dedicated hardware as well ashardware capable of executing associated software. Those of ordinaryskill in the art further understand that the exemplary hardware,software, processes, methods, and/or operating systems described hereinare for illustrative purposes and, thus, are not intended to be limitedto any particular named manufacturer.

As used herein, the singular forms “a,” “an,” and “the” are intended toinclude the plural forms as well, unless expressly stated otherwise. Itwill be further understood that the terms “includes,” “comprises,”“including,” and/or “comprising,” when used in this specification,specify the presence of stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof. It will be understood thatwhen an element is referred to as being “connected” or “coupled” toanother element, it can be directly connected or coupled to the otherelement or intervening elements may be present. Furthermore, “connected”or “coupled” as used herein may include wirelessly connected or coupled.As used herein, the term “and/or” includes any and all combinations ofone or more of the associated listed items.

It will also be understood that, although the terms first, second, etc.may be used herein to describe various elements, these elements shouldnot be limited by these terms. These terms are only used to distinguishone element from another. For example, a first device could be termed asecond device, and, similarly, a second device could be termed a firstdevice without departing from the teachings of the disclosure.

FIGS. 2 and 3 are simplified schematics illustrating an environment inwhich exemplary embodiments may be implemented. A device 20 has aprocessor 22 (e.g., “μP”), application specific integrated circuit(ASIC), or other component that executes an operating system 24 storedin a memory 26. The processor 22 may also execute a software application28 that is also stored in the memory 26. The operating system 24 acts asa host for the software application 28. The operating system 24 and thesoftware application 28 may thus cooperate to cause the processor 22 toproduce a graphical user interface 30. The graphical user interface 30is illustrated as being visually produced on a display device 32, yetthe graphical user interface 30 may also have audible features. Althoughthe device 20 is generically shown, the device 20, as later paragraphswill explain, may be a computer, a personal digital assistant (PDA), acordless/cellular/IP phone, digital music player, radio, or any otherprocessor-controlled device.

FIG. 3 illustrates a hierarchical file structure 40. The processor 22and/or the operating system 24 traverse the hierarchical file structure40 to save and to retrieve electronic files 42 that are stored in thememory 26. The operating system 24 uses the hierarchical file structure40 to organize and track the electronic files 42. The hierarchical filestructure 40 uses one or more directories to organize the electronicfiles 42 into a tree structure. FIG. 3 illustrates the hierarchical filestructure 40 having an upper level directory 44, a mid-levelsubdirectory 46, and a lower-level subdirectory 48. The generalstructure of the hierarchical file structure 40 is well-known to thoseof ordinary skill in the art and, thus, not described in detail.

Here, though, exemplary embodiments establish a scalable and secureaccess scheme for the hierarchical file structure 40. Before a user ofthe device 20 may traverse the hierarchical file structure 40 to accessthe lower-level subdirectory 48, the user must first satisfy one or moredifferent authentication requirements. The user, for example, may needto successfully authenticate any access permissions 60 associated withthe upper level directory 44. The traversing user, for example, may berequired to input a correct password before the user may continuetraversing the hierarchical file structure 40 to other files and/orlevels. When the user satisfies the access permissions 60, then the useris permitted to traverse the hierarchical file structure 40 to themid-level subdirectory 46. If the user wishes to continue traversing thehierarchical file structure 40 into the lower-level subdirectory 48,then the user must satisfy different access permissions 62 associatedwith the lower-level subdirectory 48. That is, the user is required toauthenticate two separate times in order to traverse the hierarchicalfile structure 40 from the upper level directory 44 to the lower-levelsubdirectory 48.

The mid-level subdirectory 46 may thus be publicly accessible. If a usersuccessfully authenticates the access permissions 60 of the upper leveldirectory 44, then exemplary embodiments allow the user to have globalsearch permissions in the mid-level subdirectory 46. That is, the useris “held” in the mid-level subdirectory 46 until the user successfullyauthenticates the different access permissions 62 associated with thelower-level subdirectory 48. Even though the user has global searchpermissions in the mid-level subdirectory 46, exemplary embodiments mayprevent the user from accessing the lower-level subdirectory 48 untilthe different access permissions 62 are satisfied. The user musttherefore successfully authenticate two separate times in order totraverse the hierarchical file structure 40. As later paragraphs willexplain, this access scheme is scalable, such that N different layers inthe hierarchical file structure 40 may require N differentauthentications. Progress through the hierarchical file structure 40 isimpeded by the successive requirements to authenticate. Different ownersmay establish different permissions for each hierarchical level in thehierarchical file structure 40.

Exemplary embodiments may be explained using path notation. Thehierarchical file structure 40 illustrated in FIG. 3 may be equallyrepresented by the path

d1/hold/d2/hold,

where “d1,” “d2,” and “hold” are directories. The “d1” and “d2”directories may only allow access to their respective owners. That is,directory “d1” may have its own access permission (such as the accesspermissions 60 associated with the upper level directory 44), whiledirectory “d2” has its own and different access permissions (such as thedifferent access permissions 62 associated with the lower-levelsubdirectory 48). The “hold” directory, however, allows access to anyone(as the mid-level subdirectory 46 permits). If a user wants to traversefrom directory “d1” to directory “d2,” the user must first successfullyauthenticate the access permissions of directory “d1.” If the user, forexample, enters the correct password for directory “d1,” then the usertraverses to the “d1/hold” directory. Here, though, the user is “held”in the “d1/hold” directory until the user successfully authenticates thedifferent access permissions required by the “d1/hold/d2” directory.That is, exemplary embodiments may allow the user to have global searchpermissions in the “d1/hold” directory, but the user may need to againauthenticate before accessing the “d1/hold/d2” directory. The user musttherefore successfully authenticate two separate times in order totraverse from directory “d1” to directory “d1/hold/d2.”

An analogy may help explain the different authentications. The aboveaccess scheme can be analogized to the cockpit of a jet airliner. When aco-pilot needs to access the cockpit, the co-pilot's access proceduremay be written as

firstclasscabin/door1/hold/door2.

Imagine a co-pilot walking from the jet way, through the fuselage accessdoor, and onto the jet airliner. The co-pilot enters the first classcabin area. The first class cabin (e.g., directory “firstclasscabin”)may share the same space as a first doorway (e.g., directory “door1”) tothe jet's cockpit. When the co-pilot unlocks the first doorway(directory “door1”), the co-pilot enters a holding area (e.g., directory“hold”). The co-pilot then closes and locks the first doorway (directory“door1”) to prevent unauthorized entry to the holding area (directory“hold”). The pilot in the cockpit scans the holding area (directory“hold”) and authenticates the co-pilot. When the co-pilot isauthenticated, a second door (e.g., directory “door2”) to the cockpitunlocks, thus allowing the co-pilot to enter the jet's cockpit.

Exemplary embodiments thus describe a two-phase access scheme. A firstphase describes authenticating, accessing, and “holding” in the“d1/hold” directory. When the user successfully performs a secondauthentication, then the user is permitted access to the “d1/hold/d2”directory. The user, then, must first authenticate against the accesscredentials established by an owner of the “d1” directory. If the useris successful, the user enters the “d1/hold” directory. Here, though,the user is required to authenticate against the access credentials ofan owner of the “d2” directory. If the access permissions or credentialsof directories “d1” and “d2” are different (e.g., different owners foreach directory), then the user must successfully authenticate twodifferent times. That is, the user must twice succeed to access the “d2”directory. This two-phase access scheme greatly complicates a potentialhacker's efforts and, thus, improves the security of files stored in the“d2” directory.

Exemplary embodiments may be incorporated into any operating system. Asthose of ordinary skill in the art understand, the operating system 24may be considered a master control program for the device 20. When thedevice 20 is powered, the operating system 24 loads from the memory 26(perhaps using an auto-executing “boot” program). The operating system24 (commonly abbreviated “OS” or “O/S”) manages the software andhardware components of the device 20. There are many different operatingsystems (such as MICROSOFT® WINDOWS®, MAC® OS, UNIX®, LINUX®, andSOLARIS® ), and exemplary embodiments may be integrated or incorporatedinto any operating system. Because operating systems are well known, nofurther explanation is needed.

The device 20 is only simply illustrated. Because the architecture andoperating principles of processor-controlled devices are well known,their hardware and software components are not further shown anddescribed. If the reader desires more details, the reader is invited toconsult the following sources: ANDREW TANENBAUM, COMPUTER NETWORKS(4^(th) edition 2003); WILLIAM STALLINGS, COMPUTER ORGANIZATIO ANDARCHITECTURE: DESIGNING FOR PERFORMANCE (7^(th) Ed., 2005); and DAVID A.PATTERSON & JOHN L. HENNESSY, COMPUTER ORGANIZATION AND DESIGN: THEHARDWARE/SOFTWARE INTERFACE (3^(rd). Edition 2004).

FIGS. 4 and 5 are screen prints of physical views of an enhanced accesssystem, according to exemplary embodiments. FIG. 4 illustrates POSIXstatements when a non-privileged user attempts to access theconventional directory “d1/d2” structure. As those of ordinary skill inthe art recognize, POSIX (“Portable Operating System Interface forUNIX”) is a set of standard interface statements between programs andoperating systems. Because POSIX is well-known, no further descriptionis needed. The conventional POSIX file system semantics makes itimpossible for a non-privileged user (i.e., entry of non-root passwordor other identification) to traverse the path “ . . . d1/d2/ . . . ,”where directory “d1” and directory “d2” each have 0700 permissions withrespective ownership of user “u1” and user “u2.” Here the “changedirectory” system call (e.g., “cd” or “chdir”) requires a process tohave “search” permission (or “execute” permission) in the currentdirectory before the process may traverse or advance to the nextdirectory. Directories “d1” and “d2,” though, are accessible only totheir respective owners (e.g., user “u1” and user “u2”). FIG. 5,however, illustrates the two-phase “ . . . /d1/hold/d2/ . . . ” accessscheme according to exemplary embodiments. The “hold” directory may beowned by user “u2” and has global search permissions. The “hold”directory, then, allows the “change directory” system call (e.g., “cd”or “chdir”) to successfully complete, even though the user has notauthenticated for directory “d2.”

Exemplary embodiments thus change access permissions. If a user wishesto traverse the path “ . . . /d1/d2/ . . . ,” the POSIX semanticsconcerning the “change directory” system call may prevent changingdirectories if the “current directory” (e.g., the directory from which a“setuid” system call was executed) is not accessible to a new identity.Exemplary embodiments, though, may change the permissions assigned toeach of the directories. The intermediate directory “d1/hold” has accesspermissions that allow at least access to both a current identity and anew identity. The intermediate directory “d1/hold” forces the user to“hold” with global search permissions. The user is “held” in theintermediate directory “d1/hold” until the user successfullyauthenticates for the “d1/hold/d2” directory.

FIGS. 6-8 are schematics illustrating security enhancements, accordingto exemplary embodiments. FIG. 6 again illustrates the hierarchical filestructure 40. Here, though, the hierarchical file structure 40 hasmultiple mid-level “hold” subdirectories 46 and, thus, multiplelower-level subdirectories 48. Each publicly accessible “hold” directory46 may be concatenated to create a strongly secure path. If eachdirectory {d1, d2, d(N)} is owned by a different user (that is, eachdirectory requires a different password or other access permissions),then multiple passwords have to be “cracked” to traverse thehierarchical file structure 40 to the desired electronic file(s) 42.Even if a hacker gains access to the directory “d1,” for example, thehacker is “held” or confined within one of the multiple mid-levelsubdirectories 46 ({hold1, hold2, . . . hold(N)}). That is, the hackeris prevented from accessing or seeing beyond the current d(N) directoryuntil the user satisfies one of the access requirements for the multiplelower-level subdirectories 48. Referencing FIG. 6, then, exemplaryembodiments confuse the hacker by requiring multiple choices to furthertraverse the hierarchical file structure 40. Should the hackerauthenticate the directory “d1” (illustrated as reference numeral 44),then the hacker must traverse one of the multiple mid-levelsubdirectories 46 ({hold1, hold 2, . . . hold(N)}):

hold 2/d 2, hold 3/d 2, … hold(N)/d 2.

The hacker is thus presented with multiple choices and, thus, multipleauthentication requirements. The hacker will not know the correct pathsequence, so the hacker will have to guess which of the paths containsthe desired file or data. Authorized users, however, will know thecorrect path and correctly authenticate to the desired directorylocation. Exemplary embodiments thus confine the hacker in one ofmultiple mid-level subdirectories 46 (e.g., {hold1, hold2, . . .hold(N)}) until a sublevel access permission is satisfied (such as thedifferent access permissions 62). This confine-and-authenticate featureprovides a more secure access structure for sensitive documents.

FIG. 7 illustrates security threats. The above paragraph explained how apotential hacker may be presented with multiple directory paths, thusrequiring the hacker to guess which path contains the hacker's “pot ofgold.” The hacker, then, may require more time to access a desireddirectory, and the hacker will inevitably encounter invalid paths onwrong guesses. The authorized user, though, will quickly and efficientlytraverse the hierarchical file structure 40 to the desired directory.Exemplary embodiments, then, may utilize access times and invalid pathsto determine security threats.

As FIG. 7 illustrates, then, the operating system 24 and/or the softwareapplication 28 may monitor an access time 70 that is required totraverse the hierarchical file structure 40 to a requested directory orfile (such as the electronic file 42). Exemplary embodiments may thenuse the access time 70 to determine the presence of a security threat orintrusion. The access time 70 may then be compared to a threshold time72. If the access time 70 equals or exceeds the threshold time 72, thenthe access time 70 may represent a security threat. The offending accesstime 70, for example, may indicate that a hacker is attempting (or wassuccessful) to fraudulently determine lower-level access permissions.The offending access time 70 may cause the operating system 24 and/orthe software application 28 to enter a security mode 74 of operation,set an alarm 76, and/or send a security notification 78.

FIG. 8 illustrates additional security enhancements, according toexemplary embodiments. Here exemplary embodiments track or monitorinformation associated with invalid directory paths. As the aboveparagraphs explained, exemplary embodiments may hold or confine a userwithin one of the multiple mid-level subdirectories 46 {hold1, hold2, .. . hold(N)}. The user is prevented from accessing or seeing beyond thecurrent d(N) directory until the user satisfies one or more of thedifferent access permissions 62 associated with one or more of themultiple lower-level subdirectories 48. The user may thus be faced withmultiple choices, and multiple authentication attempts, to traverse thehierarchical file structure 40. If the user fails to satisfy any accessrequirement, the operating system 24 and/or the software application 28may log a message 90 denoting an “invalid directory path.” The message90 is returned when the user tries to access or search an invalid path.Exemplary embodiments, then, may create a log 92 of each occurrence ofthe message 90, along with a corresponding date and time stamp 94.Exemplary embodiments may also log the corresponding invalid path 96.Exemplary embodiments may also log the corresponding access time 70associated with each invalid path 96. The log 92 may thus include a list98 of invalid directory paths along with each corresponding date andtime stamp 94 and invalid path 96.

The log 92 may be used to determine security threats. Exemplaryembodiments may read or scan the log 92 for offending entries that mayindicate security threats. As the above paragraphs explained, eachaccess time 70 may be compared to the threshold time 72. If the accesstime 70 equals or exceeds the threshold time 72, then the offendingaccess time 70 may indicate a security threat. Exemplary embodiments mayalso access more stringent rules, such as the number 110 of accessattempts within a predetermined time 112. If a user exceeds a maximumnumber 114 of access attempts, for example, the user may be attemptingto hack into the hierarchical file structure 40. A simple rule may evenrestrict the user to the maximum number 114 of access attempts beforeflagging a potential threat.

Exemplary embodiments are scalable. The public access permissions of theintermediate directory “d1/hold” may be contiguously applied in thehierarchical file structure (illustrated as reference numeral 40 inFIGS. 3 and 6-8) to create a scalable and secure access system. Becausethe user “holds” with global search permissions, exemplary embodimentsmay be contiguously applied to provide secure access to electronicfiles. The “d1/hold/d2” directory path structure may be repeatedly orcontiguously applied as

d1/hold/d2/hold/ . . . /d(N)/hold/sensitivedocument,

with N representing an integer. Each directory {d1, d2, . . . d(N)} onlyallows access to its respective owner. That is, each directory d(N) mayrequire different access permissions (e.g., passwords). Each “hold”directory may have the same permissions (such as 555 r-xr-xr-x). Thepath repository is thus 2N deep, with each directory d(N) being owned bya different user with access restricted to a single owner (i.e., chmod700 d[1 . . N] rwx------). A complete traversal of the hierarchical filestructure 40 (or “tree”) may require successfully authenticating Ndifferent times. Increasing the protection strength means increasing thedepth N and, correspondingly, the number of authentication attempts.

FIGS. 9-13 are schematics illustrating examples of enhanced file accessstructures, according to exemplary embodiments. These examples combinethe strength of N different passwords or public keys in order to gainaccess to sensitive data. FIG. 9, for example, illustrates a trusted keyserver 120 that implements the “d1/hold/d2” directory path structure tocreate a very strong protection model. Conventional access schemes areall based on monitoring/alerting when suspicious access patterns aredetected. The conventional access schemes are “best-effort” and onlylimit an amount of data stolen, using a single password per documentrepository. The conventional access schemes, however, cannot preventaccess to sensitive data. Exemplary embodiments, then, may combineoperating/file-system security practices with public-key encryption andtrusted key-server technologies to create a novel combination of filesystem security and authentication key distribution.

As FIG. 9 illustrates, the device 20 communicates with the trusted keyserver 120 via a communications network 122. As each new directory d(N)is encountered when traversing the hierarchical file structure(illustrated as reference numeral 40 in FIGS. 3 and 6-8), the operatingsystem 24 and/or the software application 28 may query the trusted keyserver 120 for the access permissions of the “next” d(N+1) directory inthe path. A query 124 is sent to the trusted key server 120 via thecommunications network 122. The query 124 may include information thatspecifies the current directory d(N) and/or the next directory d(N+1) inthe path. The trusted key server 120 retrieves the access permissions 60(perhaps from an access database 26 that stores access permissions,passwords, and/or authentication requirements). The trusted key server120 sends a query response 128 comprising the access permissions 60(i.e., the credentials of the owner of the “next” d(N+1) directory inthe path). When the device 20 receives the query response 128, theoperating system 24 and/or the software application 28 may run thesource codes “run.ksh,” “su.exp,” and “traverse.ksh” that arerespectively illustrated in FIGS. 10, 11, and 12. The “su.exp” and“traverse.ksh” source codes (respectively illustrated in FIGS. 11 and12) may be repeated for each number N of directories in the desiredpath. When the user is successful, the user may access a file or data atan end of the path.

FIG. 13 illustrates bulk access permissions. When the operating system24 and/or the software application 28 query the trusted key server 120for access permissions, here the trusted key server 120 retrieves theaccess permissions 60 for the entire hierarchical file structure(illustrated as reference numeral 40 in FIGS. 3 and 6-8). The device 20,for example, may send information that identifies the hierarchical filestructure 40 by path, name, number, or some other identifyinginformation. The query 124 may additionally or alternatively identifyeach directory path {d1 . . . d(N)} in the hierarchical file structure40. When the trusted key server 120 sends the query response 128, thetrusted key server 120 sends bulk access permissions 140. That is, thetrusted key server 120 sends all the access permissions 60 that may berequired to traverse any path in the hierarchical file structure 40.This alternate mechanism may provide faster access times for aparticular directory path. When the device 20 receives the queryresponse 128, the operating system 24 and/or the software application 28may again run the source codes “run.ksh,” “su.exp,” and “traverse.ksh”(respectively illustrated in FIGS. 10-12).

Exemplary embodiments may be applied regardless of networkingenvironment. The communications network 122 may be a cable networkoperating in the radio-frequency domain and/or the Internet Protocol(IP) domain. The communications network 122, however, may also include adistributed computing network, such as the Internet (sometimesalternatively known as the “World Wide Web”), an intranet, a local-areanetwork (LAN), and/or a wide-area network (WAN). The communicationsnetwork 122 may include coaxial cables, copper wires, fiber optic lines,and/or hybrid-coaxial lines. The communications network 122 may eveninclude wireless portions utilizing any portion of the electromagneticspectrum and any signaling standard (such as the I.E.E.E. 802 family ofstandards, GSM/CDMA/TDMA or any cellular standard, and/or the ISM band).The communications network 122 may even include powerline portions, inwhich signals are communicated via electrical wiring. The conceptsdescribed herein may be applied to any wireless/wireline communicationsnetwork, regardless of physical componentry, physical configuration, orcommunications standard(s).

FIGS. 14 and 15 are schematics illustrating more examples of enhancedfile access structures, according to exemplary embodiments. FIG. 14graphically illustrates another hierarchical file structure 40, whileFIG. 15 is a screen print of the physical structure. The desiredelectronic file 42 (e.g., the “pot of gold”) has the following path

d1/hold2/d2/hold1/potofgold.

If a potential hacker gains access to directory “d1” (illustrated asreference numeral 150), then the hacker is immediately presented with achoice of subdirectories “d1/hold1” and “d1/hold2” (illustrated,respectively, as reference numerals 152 and 154). The subdirectories“d1/hold1” and “d2/hold2” are owned by a different user (e.g., “user2”). The hacker must now successfully complete another authenticationattempt (as defined by “user 2”), and the hacker must also select thecorrect path. If the hacker satisfies the “user 2” permissions fordirectory “d2,” and the hacker correctly chooses path d1/hold2, then thehacker encounters more path choices. The subdirectories“d1/hold2/d2/hold1” and “d1/hold2/d2/hold2” (illustrated, respectively,as reference numerals 156 and 158) are owned by yet another differentuser (e.g., “user 3”). The hacker must again successfully completeanother authentication attempt (as defined by “user 3”), and the hackermust also select the correct path. If the hacker satisfies the “user 3”permissions, and if the hacker chooses the correct path, then the hackermay access the desired file 42 (e.g., the “pot of gold”).

Exemplary embodiments thus provide strong and scalable access protectionin access file systems. Exemplary embodiments also provide programmaticaccess protection by combining operating system security at the filesystem layer with public key encryption. Exemplary embodiments alsoprovide an alternative to file encryption, as a loss of an encryptionkey renders an electronic file unusable. Exemplary embodiments may alsoreduce or eliminate the chance of stolen data if a breach occurs, aslong as the number of stolen passwords is less than N, where Ncorresponds to the directory layers d(1 . . . N), as explained above. Aslong as the number of stolen passwords is less than N, the sensitivedocument repository is inaccessible.

FIG. 16 is a schematic illustrating still more exemplary embodiments.FIG. 16 is a generic block diagram illustrating the operating system 24,and/or the software application 28, may operate within aprocessor-controlled device 200. The operating system 24 and/or thesoftware application 28 may be stored in a memory subsystem of theprocessor-controlled device 200. One or more processors communicate withthe memory subsystem and execute the operating system 24 and/or thesoftware application 28. Because the processor-controlled device 200illustrated in FIG. 16 is well-known to those of ordinary skill in theart, no detailed explanation is needed.

FIG. 17 depicts other possible operating environments for additionalaspects of the exemplary embodiments. FIG. 17 illustrates that theexemplary embodiments may alternatively or additionally operate withinvarious other devices 300. FIG. 17, for example, illustrates that theoperating system 24 and/or the software application 28 may entirely orpartially operate within a set-top box (“STB”) (302), a personal/digitalvideo recorder (PVR/DVR) 304, personal digital assistant (PDA) 306, aGlobal Positioning System (GPS) device 308, an interactive television310, an Internet Protocol (IP) phone 312, a pager 314, acellular/satellite phone 316, or any computer system, communicationsdevice, or processor-controlled device utilizing the processor 22 and/ora digital signal processor (DP/DSP) 318. The device 300 may also includewatches, radios, vehicle electronics, clocks, printers, gateways,mobile/implantable medical devices, and other apparatuses and systems.Because the architecture and operating principles of the various devices300 are well known, the hardware and software componentry of the variousdevices 300 are not further shown and described. If, however, the readerdesires more details, the reader is invited to consult the followingsources: LAWRENCE H ARTE et al., GSM S UPERPHONES (1999); SIEGMUND REDLet al., GSM AND PERSONAL COMMUNICATIONS HANDBOOK (1998); and JOACHIMTISAL, GSM CELLULAR RADIO TELEPHONY (1997); the GSM Standard 2.17,formally known Subscriber Identity Modules, Functional Characteristics(GSM 02.17 V3.2.0 (1995-01))“; the GSM Standard 11.11, formally known asSpecification of the Subscriber Identity Module-Mobile Equipment(Subscriber Identity Module-ME) interface (GSM 11.11 V5.3.0 (1996-07))”;MICHEAL ROBIN & MICHEL POULIN, DIGITAL TELEVISION FUNDAMENTALS (2000);JERRY WHITAKER AND BLAIR BENSON, VIDEO AND TELEVISIO ENGINEERING (2003);JERRY WHITAKER, DTV HANDBOOK (2001); JERRY WHITAKER, DTV: THE REVOLUTIONIN ELECTRONIC IMAGING (1998); and EDWARD M. SCHWALB, ITV HANDBOOK:TECHNOLOGIES AND STANDARDS (2004).

FIGS. 18 and 19 are flowcharts illustrating a method of securing accessto a file system, according to exemplary embodiments. An operatingsystem, having or accessing a hierarchical file structure, is stored inmemory (Block 400). A directory is created, established, and/or accessedin the hierarchical file structure that has access permission(s) definedby a first owner (Block 402). A subdirectory is created, established,and/or accessed in the directory that is owned by a second owner (Block404). A sub-level subdirectory is created, established, and/or accessedin the subdirectory having access permissions defined by the secondowner (Block 406). A change directory system call is permitted toexecute in the directory (Block 408), subdirectory (Block 410), and/orsub-level subdirectory (Block 412) for a user that successfullyauthenticates the access permission(s) of the directory. A directorysearch is executed (Block 414).

The flowchart continues with FIG. 19. A time to access the sub-levelsubdirectory is monitored (Block 416) and compared the access time to athreshold time (Block 418). If the time to access is less than thethreshold time (Block 420), then no security threat is presumed (Block422). If, however, the time to access is equal to or greater than thethreshold time (Block 420), then a threat condition is notified (Block424).

Exemplary embodiments may be physically embodied on or in acomputer-readable storage medium. This computer-readable medium mayinclude CD-ROM, DVD, tape, cassette, floppy disk, memory card, andlarge-capacity disks. This computer-readable medium, or media, could bedistributed to end-subscribers, licensees, and assignees. These types ofcomputer-readable media, and other types not mention here but consideredwithin the scope of the exemplary embodiments. A computer programproduct comprises processor-executable instructions for securing accessto a file system.

While the exemplary embodiments have been described with respect tovarious features, aspects, and embodiments, those skilled and unskilledin the art will recognize the exemplary embodiments are not so limited.Other variations, modifications, and alternative embodiments may be madewithout departing from the spirit and scope of the exemplaryembodiments.

1. A system, comprising: a hardware processor; and a memory device, thememory device storing an operating system associated with a hierarchicalfile structure, the operating system when executed causing the hardwareprocessor to perform operations, the operations comprising: establishinga directory in the hierarchical file structure; establishing multipledirectory paths associated with the directory, each one of the multipledirectory paths associated with a different access permission, and someof the multiple directory paths purposefully invalid as invaliddirectory paths; summing a count of the invalid directory paths selectedduring authentication attempts associated with the directory; comparingthe count of the invalid directory paths to a threshold value; andgenerating a security threat in response to the count of the invaliddirectory paths exceeding the threshold value.
 2. The system of claim 1,wherein the operations further comprise generating an alarm in responseto the security threat.
 3. The system of claim 1, wherein the operationsfurther comprise generating a notification in response to the securitythreat.
 4. The system of claim 1, wherein the operations furthercomprise determining a time associated with the authentication attempts.5. The system of claim 4, wherein the operations further comprisecomparing the time to a threshold access time.
 6. The system of claim 5,wherein the operations further comprise generating another securitythreat in response to the time exceeding the threshold access time. 7.The system of claim 1, wherein the operations further compriseassociating the threshold value to a user.
 8. A method, comprising:establishing, by a server, a directory in the hierarchical filestructure; establishing, by the server, multiple directory pathsassociated with the directory, each one of the multiple directory pathsassociated with a different access permission, and some of the multipledirectory paths purposefully invalid as invalid directory paths;summing, by the server, a count of the invalid directory paths selectedduring authentication attempts associated with the directory; comparing,by the server, the count of the invalid directory paths to a thresholdvalue; and generating, by the server, a security threat in response tothe count of the invalid directory paths exceeding the threshold value.9. The method of claim 8, further comprising generating an alarm inresponse to the security threat.
 10. The method of claim 8, furthercomprising generating a notification in response to the security threat.11. The method of claim 8, further comprising determining a timeassociated with the authentication attempts.
 12. The method of claim 11,further comprising comparing the time to a threshold access time. 13.The method of claim 12, further comprising generating another securitythreat in response to the time exceeding the threshold access time. 14.The method of claim 8, further comprising associating the thresholdvalue to a user.
 15. A memory device storing instructions that whenexecuted cause a hardware processor to perform operations, theoperations comprising: establishing a directory in the hierarchical filestructure; establishing multiple directory paths associated with thedirectory, each one of the multiple directory paths associated with adifferent access permission, and some of the multiple directory pathspurposefully invalid as invalid directory paths; summing a count of theinvalid directory paths selected during authentication attemptsassociated with the directory; comparing the count of the invaliddirectory paths to a threshold value; and generating a security threatin response to the count of the invalid directory paths exceeding thethreshold value.
 16. The memory device of claim 15, wherein theoperations further comprise generating an alarm in response to thesecurity threat.
 17. The memory device of claim 15, wherein theoperations further comprise generating a notification in response to thesecurity threat.
 18. The memory device of claim 15, wherein theoperations further comprise determining a time associated with theauthentication attempts.
 19. The memory device of claim 18, wherein theoperations further comprise comparing the time to a threshold accesstime.
 20. The memory device of claim 19, wherein the operations furthercomprise generating another security threat in response to the timeexceeding the threshold access time.